AWS DMS
参考
AWS DMS（Data Migration Service）とは
その名の通り、とあるデータベースから別データベースにデータを移行させるサービス。
もっというと、AWSサービスにデータを移行するやつ。
AWS Database Migration Service (AWS DMS) は、データベースと分析のワークロードを迅速かつ安全に、AWS に移行するのを支援するマネージド移行およびレプリケーションサービスです。移行中でもソースデータベースは完全に利用可能な状態に保たれ、データベースを利用するアプリケーションのダウンタイムは最小限に抑えられます。
データベースというのはRDBMSに限らないことに注意されたし。
登場人物
https://scrapbox.io/files/63ca11c0f3f173001de96a85.png
Source database
移行元のデータベース
データベースなら何でも良い認識。というのは、オンプレ環境でも、別VPCのEC2, RDSでも何でも。
Source Endpoint
AWS DMSメンバーの一人。
移行元のデータベースの代理店的な役割。
レプリケーションインスタンスに繋げるためのエンドポイント。
Replication Instance
AWS DMSメンバの一人。
移行元から移行先データベースにデータを移行する際の中間サーバー。
移行の処理（Replication Task）をこのサーバー上で行う。
移行処理の速度は、このインスタンスの強さにかかってると言っても過言ではない。
Replication Task
AWS DMSメンバの一人。
移行処理の内容を定義し、実際に移行するジョブのようなものと思えばいい。
なので、移行の成功/失敗とかいうステータスも保持してる。
Target Endpoint
AWS DMSメンバの一人。
移行先データベースの代理店的な役割。
レプリケーションインスタンスに繋げるためのエンドポイント。
Target database
移行先のデータベース
データベースなら何でも良い認識。というのは、オンプレ環境でも、別VPCのEC2, RDSでも何でも。
ただ、基本的にはRDSになることが多いように感じる。
わざわざオンプレ環境やEC2にデータを移行することは少ないようなイメージ。
移行の様々なネットワークパターン
基本的に、以下のことを頭に入れておくことが大事。
1. 「Source Database」と「Replication Instance」が通信できる状態
2. 「Replication Instance」と「Target Instance」が通信できる状態。
この2つの状態を意識しておかないと、データの移行の前提すらできてないことになる。
その上で、以下にネットワークパターンがあるので参照されたし。
Tips & 注意点
移行エラーが発生した時にいつでもログを確認できるよう、Cloudwatch Logsは有効化しておけ
結構な確率で検証時にエラーも起きるので、エラーログが見れないのは辛いよ。
テーブルマッピングにて、ソースに「%」だけ指定しちゃうとシステムテーブルもレプリケーションしちゃうのだが...
これやるとエラーになるので気をつけて。
AWS管轄のMySQL（RDS for MySQL, Aurora MySQL）だと、システムテーブル（mysql）は管理者権限でも直接の更新・削除ができない。
なので、AWS DMSでmysqlを移行しようとすると、その権限違反に触れて落ちる。
よくある質問
q.icon DMSでレプリケーションを実施する前に、ターゲット側にソースと同じスキーマ（DB）を用意しておく必要があるか？
a.icon 必ず用意しておく必要があるわけではない。場合による。
例えば、同じDBエンジン x メジャーバージョン間で移行する場合は、事前に用意する必要はない。DMSが自動でターゲット側に用意してくれる。
逆に、別DBエンジンとかになってくると、事前に用意する必要がある。
q.icon 別DBエンジンのデータを移行するということがなぜ可能なのか？詳細はどのような実現方法になってるのか？
a.icon
q.icon DMSは、マルチソースレプリケーション的なことが可能？つまり、2つ以上のDBから1つのDBにレプリケーションする感じ。
a.icon 可能。可能ではあるが、レプリケーション時にデータ更新が競合しないかどうかは慎重に考慮しておけ。
2つのDBから同じスキーマに対して更新する際など、もし同じプライマリキーがあったりしたらバグる。
hr.icon
hr.icon
ざっと調査ログ
hr.icon
基本
データベースのデータ移行を支援するサービス。
オンプレ - AWS間、オンプレ - オンプレ間、（AWS - AWS間）のデータ移行が可能。
AWS - AWS間は別サービス推奨とのこと。
ユースケース
クラウドシフトしたサーバーへのデータ移行、検証目的でのデータレプリケーション、遠隔地バックアップなど
DMSの構成
https://scrapbox.io/files/63ca11c0f3f173001de96a85.png
Replication Instance (データレプリケーションを実行するインスタンス)
Replication Task (データレプリケーションの実行単位)
Source Endpoint (ソースデータベースへの接続定義)
Target Endpoint (ターゲットデータベースへの接続定義)
レプリケーション方法は3パターン
全ロード ソースデータベースからターゲットデータベースへ指定したテーブルデータがそのまま移行されます。
全ロード + CDC ソースで変更をキャプチャしながら、全ロードが実行されます。
全ロードが完了すると、キャプチャされた変更がターゲットにレプリケーションされます。
最終的に、変更のレプリケーションは安定した状態に到達します。
CDC のみ ネイティブのエクポート/インポートツールで一括ロードした後に、DMSは差分のみをレプリケーションします。
検証してみる
なんか上手いことレプリケーションできねぇ....むずいな....
ちょっと、公式ドキュメントを元に検証することにする
RDS for MySQL 5.7 => RDS for MySQL 5.7で無駄な移行を試す
todo_done.iconVPCを適当に作成
todo_done.iconパラメータグループ作成
todo_done.iconソースRDSを作成（パラメータグループ付与）（RDS for MySQL 8.0）
todo_done.iconターゲットRDS作成（RDS for MySQL 8.0）
todo_done.iconエンドポイント作成、レプリケーションインスタンス作成、タスク作成
todo_done.icon レプリケーション実行
エラー発生
バイナリログが有効になってないとエラー発生する
バイナリログのフォーマットがROWじゃないとエラー発生する
q.icon DMSでレプリケーションを実施する前に、ターゲット側にソースと同じスキーマ（DB）を用意しておく必要がある？？
a.icon 場合による。同じエンジンを利用してるなら、スキーマを用意する必要はなく、自動で作ってくれる可能性が高い。
ただ、別のメジャーバージョンとかだとわんちゃん厳しい可能性はある。
トラシュー方法
テーブル統計を確認
どのテーブルがバグってるか確認
awsdms_apply_exceptions を確認する。
タスクログを確認する
https://scrapbox.io/files/63d0af8ae64bb4001dc2267e.png